FrontPage/Generic Guidlines For Kexi Development

Kexi's Environment: Kexi and Calligra framework/suite

 js, lucijan, 2003-10-19

Why Kexi does not behave as well as a Calligra application using Calligra libraries compared to others apps from the family?

• Kexi, unlike (all?) other Calligra applications is not document-driven

Kexi is project-driven instead. Thus it is conceptually more like KDevelop.

• Application's environment.

Typical Calligra application is built upon the fact that there is a main document (that also can act as KPart) for application view, and most application logic is built around this single native format/mime type and KPart class that uses data in this single format.

Kexi has more distributed nature, there are more than just one mode (or two) for editing document or viewing it as read-only (both modes for e.g. KWord uses mostly the same KPart widget(s), only with disabled/enabled certain actions). Some Kexi KParts has editors that are built as strictly different components thant these used for viewing (example "table altering" dialog versus table/query data view).

• Storage differences

Calligra depends on storing its native format in single file (in some cases, it can be non-xml but still it is self-contained file)

Kexi has many storage options, since one of its goal is integration of external database systems. Kexi allows you to save short xml informational file (something like a shortcut to db connection) allowing you to connect again to database where your project is stored.

Other project storage method for Kexi is to use file-based databases (currently, bianary SQLite-compatible with Kexi system objects inside). For end-user convenience, such a SQLite database file can be self contained and no additional information (in additional xml file) is required (although it is possible to have one).

• Calligra behaves differently at opening projects than Kexi.

When not native format encountered, Calligra framework automatically invokes filters to convert a foreign format into its singe native format.

Kexi is not expected to do so: there is generalizetion developed inside KexiDB module; this module handles all differences "on-line". Otherwise it would be impossible to use Kexi: you don't need to convert e.g. MySQL-embedded-file to a SQLite file, since if there is a driver for MySQL-embedded it is still neutral to SQLite one.

Similarly, Kexi does not download all data from SQL server and then it do not converts its format to "common" data representation and then operates on this representation. Look that so called "filter chains" from Calligra framework could force Kexi to do so (otherwise owful wrapping should be added), while in most cases the only thing that is converted in Kexi projects (and rather on-demand) are database schemas.

Above notes do not mean that Kexi is designed to lack filters functionality. Kexi filters functionality is designed with a knowledge that i.e. importing database schemas is not fully automatic, because there is always not enough db schema information (e.g. whe migrating database from raw MySQL format to Firebird-driven Kexi project). The same for export feature: after exporting, much of project's information can dissapear. You can say it is quite like exporting e.g. KWord document to, say, RTF. Yes, but Kexi often has to offer additional dialogs to ask user for additional hints -- summing up, KO filter chains are not so usable in Kexi, since we are not performing just "convert-file-to-file" task.

Why is Kexi a member of the Calligra suite?

• Kexi is still part of the Calligra suite, which from end-user perspective, means that the strategy is the same as before. This implies that we will do our best to honour Calligra release schedules and feature freezes.

• Kexi is a missing application for Free platforms like Linux, *BSD

• It (will be) still properly integrated with other Calligra compontents (Words mailmerge, KChart graphs, Sheets tables ...) and/or reuse them

Any comments and ideas and further proposals are heavily welcome :)